计划阅读调试下Dubbo的源码,结合官方源码分析Dubbo,自身再分析总结
本文对应的Dubbo 服务引入
源码分析
引入服务
接着上一篇,进入createProxy
1 | "unchecked", "rawtypes", "deprecation"}) ({ |
上面逻辑比较简单,主要是加载注册地址以及对多个注册地址或者直连地址的合并处理。核心部分在refprotocol.refer
invoker
refprotocol在当前环境下对应的是RegistryProtocol。
这段代码分析的时候涉及到多个动态加载的类。在进入分析前先罗列下,后续我再把堆栈打印出来直观展示
RegistryProtocol#refer -> ZookeeperRegistryFactory#getRegistry
-> ZookeeperRegistry -> CuratorZookeeperTransporter#connnect -> CuratorZookeeperClient
RegistryProtocol#refer -> MockClusterWrapper#join -> MockClusterInvoker#join -> FailoverCluster#join
下面继续调试代码
1 | public class RegistryProtocol implements Protocol { |
doRefer方法中的 Invoker invoker = cluster.join(directory);
这里需要特殊说明下,这里是通过Wrapper类进到核心的逻辑类FailoverCluster,至于SPI如何调用到Wrapper的类,可以看下 Dubbo源码分析5-Dubbo 服务导出4
对应的堆栈如下图所示
进入cluster#join对应的failovercluster中
1 | public class FailoverCluster implements Cluster { |
proxy
上一节分析了invoker的来源,得到invoker其实是MockClusterInvoker,下面接着分析另外一个核心点,proxyFactory.getProxy(invoker)
是如何创建proxy
proxyFactory是通过自适应SPI来实例的。在服务导出的时候,分析过他getInvoker实现
现在我们使用Arthas来看看,这个动态生成的类是怎么样的
1 | package com.alibaba.dubbo.rpc; |
可以看出来还是比较简单的,getProxy从invoker中拿到url,然后根据url中的proxy参数来获取到ProxyFactory。这里用的是默认的javassitProxyFactory
我们继续往下看
1 | // 首先还是从基类分析 |
上面的代码主要涉及ccp、ccm两部分,其中ccp用于生成interface的实现类,ccm用于生成proxy的基类
ccp生成的是
1 | package com.alibaba.dubbo.common.bytecode; |
ccm生成的是
1 | package com.alibaba.dubbo.common.bytecode; |
最终我们获取到了生成的Proxy0,大功告成